Implement switch statements and expressions#9
Implement switch statements and expressions#9AlexisMardas wants to merge 1 commit intoRandgalt:masterfrom
Conversation
| * @param args the values to be placed instead of the format's placeholders | ||
| */ | ||
| public Builder beginSwitchStatement(String expressionFormat, Object... args) { | ||
| add("switch ("+expressionFormat+") {\n", args); |
There was a problem hiding this comment.
We must not assume where newlines, indenting, tabs, etc. go. The library already has mechanisms for users to specify these.
There was a problem hiding this comment.
The already existing methods that implement control flows do the same thing, adding newlines and adjusting the indentation. I tried to be consistent with the codebase and create methods that follow the same logic. If that's a problem would you suggest I simply remove newline characters?
| // If the body contains multiple lines or expressions it should be | ||
| // contained in braces | ||
| if (bodySide.lines().count() > 1 || bodySide.split(";").length > 1) { | ||
| bodySide = "{ " + bodySide + " }"; |
There was a problem hiding this comment.
This is coming up in the lambda PR too. We need a general way for users to specify how to output lambda-like code bodies. We can't assume how the braces are positioned around the code block.
There was a problem hiding this comment.
How do you suggest I tackle this issue? Would simply removing these lines of code and assuming that the user includes the braces in the code block when necessary resolve the problem?
There was a problem hiding this comment.
As I just wrote in the lambda PR, I'd like to see a new builder class shared by both lambda and this PR that is similar to CodeBlock. Users should be able to specify exactly (and in detail) how newlines, indents, etc. are generated.
i.e.
Some people will want:
switch (foo) {
case X -> { yield 10; }
}
Some will want:
switch (foo) {
case X ->
{ yield 10;
}
}
Some will want:
switch (foo) {
case X -> {
yield 10;
}
}
And every variation inbetween
|
I'm having a hard time keeping up with reviews on this project. Do you know anyone else who can help review? |
|
Please see: #16 - let's use that class as a basis for switch (or vice versa). Work with @HliasMpGH to come up with a generalization. Switch expressions and lambdas are nearly identical in terms of bodies. |
2 participants
** SECOND PART OF ISSUE #5 **
This feature enables the use of traditional switch statements and extended switch expressions within CodeBlocks and MethodSpecs. The necessary testing has also been conducted.
Now let's have a look at the code necessary to create a simple method that contains a switch statement. The following code:
Generates this output:
As you can see the methods implemented follow the logic of the already existing ones that are used to generate control flows, but are specifically created to accomodate switch statement generation.
Now let's have a look at another example, that showcases the code necessary to create a CodeBlock that consists of an extended switch expression. The following code:
Can be used to generate this output:
It should be noted that if the body of each case included more than one lines or statements, then it would be automatically enclosed in braces.
The entire feature relies heavily on the already used placeholder mechanism of the project, both to remain consistent with the rest of the codebase and to provide users with the flexibility required to create switch statements and expressions. Where necessary, method overloads have also been implemented.